home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20020314-20021006 / 000049_ishikawa@yk.rim.or.jp_Sat Apr 27 10:48:43 EDT 2002.msg < prev    next >
Text File  |  2002-10-06  |  8KB  |  184 lines
  1. Article: 13340 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
  3. From: Ishikawa <ishikawa@yk.rim.or.jp>
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
  6. Date: Sat, 27 Apr 2002 10:49:21 +0900
  7. Organization: Ye 'Ol Disorganized NNTPCache groupie
  8. Lines: 160
  9. Message-ID: <3CCA03A1.59EF10C9@yk.rim.or.jp>
  10. References: <3CAFF81C.8039CBF8@yk.rim.or.jp> <3CC84CA6.D49F85EC@yk.rim.or.jp> <aa9l3h$4s4$1@watsol.cc.columbia.edu> <3CC98FC0.AADA5130@yk.rim.or.jp> <aac6cv$rlm$1@watsol.cc.columbia.edu>
  11. NNTP-Posting-Host: pl940.nas911.n-yokohama.nttpc.ne.jp
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=iso-2022-jp
  14. Content-Transfer-Encoding: 7bit
  15. X-Trace: news.rim.or.jp 1019872163 43612 210.139.42.172 (27 Apr 2002 01:49:23 GMT)
  16. X-Complaints-To: root@rim.or.jp
  17. NNTP-Posting-Date: Sat, 27 Apr 2002 01:49:23 +0000 (UTC)
  18. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
  19. X-Accept-Language: ja, en
  20. Cache-Post-Path: duron!unknown@localhost
  21. X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13340
  23.  
  24. Frank da Cruz wrote:
  25.  
  26. > : I remember Fujii-san from KEK helped
  27. > : the popularization of Kermit on Japanese PC.
  28. > :
  29. > Yes, the NEC PC-9801.  This was in the pre-Windows days, when PCs
  30. > ran only DOS (or very early forms of Unix).  I found it quite
  31. > amazing.  The keyboard driver -- which lets you type Romaji, puts up
  32. > little menus, learns from you, guesses which Kanji you mean, etc --
  33. > seemed to be about 100 times more powerful than the PC itself :-)
  34. > 
  35. Oh, those were the days. I used to get a kick out of
  36. showing these features in one of our home-brew programs at the office
  37. to visiting overseas dignitaries
  38. and hearing the "Oh" and "Wow".
  39.  
  40.  
  41. > Fujii-san wrote a book, "MS-Kermit Nyumon":
  42. > 
  43. >   http://www.columbia.edu/kermit/manuals.html
  44. > 
  45. > About the PC-9801 version of MS-DOS Kermit.  I suppose this is now a
  46. > rare collector's item.
  47. Yes, it is. The next time I see it at a second hand book store,
  48. I will grab it right away.
  49.  
  50. >  It is definitely the thinnest of all Kermit
  51. > books.  An advantage of Japanese writing: you don't have to use as
  52. > much paper!
  53. Until seeing the page, I didn't know books in languages other than
  54. in English and Japanese existed. Kermit, the program, seems to
  55. be used all over the world!
  56.  
  57. >   http://www.columbia.edu/kermit/k95faq.html (third item)
  58.  
  59. Product naming is full of pitfalls. I understand.
  60.  
  61. > : Anyway, below is the result of
  62. > : a little experiment I did to clear up
  63. > : my understanding of some options, etc..
  64. > : Hope some people might find this useful.
  65.  
  66. > So Cases 1 and 2 are the same, but "set control unprefix all" is a
  67. > bit faster than "set unprefix none".  OK, I believe it.  Both
  68. > commands work on the same table, but perhaps over the years the code
  69. > for the two commands has gotten slightly out of sync.  It might well
  70. > be that prefixing or not prefixing just one certain character (such
  71. > as NUL, ASCII 0) can make a significant difference in this case,
  72. > since executable binaries tend contain lots of NULs.  Maybe that's
  73. > the difference between the two commands.
  74. > 
  75.     ... 
  76. > I'll make a note to fix between the two unprefixing command in the
  77. > next release.
  78. > 
  79.  
  80. Thank you for studying the data.
  81. To give you some more data point,
  82. I did one more experiment. [This is going to be the final test result
  83. until probably the next year when I need to
  84. use Kermit on a different platform and use different feature :-) ]
  85.  
  86. Based on your observation that the executable wermit may have skewed
  87. distribution of octet values (very likely indeed), I counted the
  88. frequency of each octet value.  To make a long story short, I found
  89. that 0 is most frequent as you guessed correctly.
  90.  
  91. In the data below, value:frequency pairs are shown.
  92.  
  93. ishikawa@duron$ ./count < wermit
  94. 0:500744 1:14331 2:7721 3:6147 4:12153 5:13718 6:6117 7:8356 
  95. ********  Almost 1/4 of the total!!!
  96. 8:94806 9:4413 10:6944 11:2882 12:6407 13:3256 14:2521 15:18694 
  97. 16:16293 17:3848 18:7288 19:2430 20:4744 21:4601 22:6197 23:4869 
  98. 24:3524 25:2223 26:2685 27:5758 28:7488 29:8009 30:3761 31:20317 
  99. 32:80939 33:6472 34:2670 35:4321 36:4350 37:7897 38:6274 39:3488 
  100. 40:5673 41:3466 42:1745 43:1952 44:4746 45:4373 46:6375 47:2859 
  101. 48:4359 49:4954 50:2970 51:1510 52:2852 53:7989 54:1523 55:1883 
  102.     ...
  103.  
  104. Of the approximately 2MB ( 2183313 bytes to be exact), close to
  105. one fourth (1/4) is byte with value 0!
  106.  
  107. So again, I got curious and created a gzipped file from wermit.
  108.                 cp wermit /tmp/wermit
  109. ishikawa@duron$ gzip --best -v /tmp/wermit
  110. /tmp/wermit:     63.3% -- replaced with /tmp/wermit.gz
  111. ishikawa@duron$ ls -l /tmp/wermit*
  112. -rwxr-xr-x    1 ishikawa users      800501 Apr 27 10:26 /tmp/wermit.gz*
  113.  
  114. Why compression?
  115. Since compressed file usually have more balanced, close to uniform
  116. byte value distribution, I tried sending the compressed file and
  117. measured CPS to see if the uniform distirbution 
  118. closes the gap between observed CPS values in case-3 and case-4. 
  119. (The uniformity is like this. It is indeed very good.
  120. ishikawa@duron$ ./count < /tmp/wermit.gz
  121. 0:2903 1:3066 2:2973 3:3186 4:2985 5:2881 6:3127 7:3284 
  122. 8:2993 9:3010 10:2990 11:2996 12:2944 13:3282 14:3016 15:3456 
  123. 16:2729 17:2907 18:2784 19:3009 20:2820 21:2889 22:3073 23:3147 
  124. 24:2945 25:3013 26:3033 27:3129 28:2889 29:3015 30:3113 31:3700 
  125. 32:2844 33:2866 34:2722 35:3060 36:2838 37:2790 38:2891 39:3220 
  126. 40:2948 41:2901 42:2798 43:3017 44:3006 45:3199 46:2923 47:3343 
  127.     ...
  128.  
  129.  
  130. The new CPS values are shown below
  131. appended to the original table.
  132.  
  133.  
  134. >CPS (measured into 20% of the transfer. The file is 2183313 bytes.)
  135. >============================================================================
  136. >CPS:      case-1  case-2   case-3  case-4
  137. >---------------------------------------------------------------------------
  138. >send:    3010     3009    3835    3621
  139. >receive: 2973     2972       3786    3568
  140.  
  141. CPS measured for compressed wermit file. (wermit.gz)
  142. I only measurement for case-3 and case-4.
  143. (Also, the measurement was done into 50% (approximately 400KB) 
  144. of transfer.)
  145.                            case-3  case-4
  146.                            3796    3721    
  147.                            3753    3702
  148. ===========================================================================
  149.  
  150.  
  151. So as you have again correctly guessed, the skewed distribution of
  152. octet values (0 being dominant) had something to with the CPS under
  153. different control/prefix setting, i.e., "set control unprefixed all"
  154. vs "set prefixing none".
  155. With the uniform distribution of octet values, the difference
  156. decreases very much.  (So maybe the code path is indeed similar(?) and
  157. has not diverged very much??? The slight difference about 50 could be
  158. indeed a statistical fluke, but... )
  159.  
  160. Hope this helps.
  161.  
  162. Thank you again for the great support.
  163.  
  164. Always hoping to send back feedback to improve KERMIT.
  165.  
  166. Ishikawa, Chiaki
  167.  
  168. PS:
  169.  
  170. >case-4: `case-1` setting 
  171. >    +  "set prefixing none"
  172. >    (BTW, Completion doesn't show "none" as a valid third argument.)
  173.  
  174. I noticed a few cases where an accepted option is not shown in the
  175. response to "?" completion helper listing.  The above is such a case.
  176. I found the effect of "minimal" and "none" is slightly
  177. different and so "none" ought to be listed IMHO.
  178.  
  179. To wit,
  180. (/home/ishikawa/KERMIT/new-kermit/receive/) C-Kermit>set prefixing ?
  181. control-character prefixing option, one of the following:
  182.  all       cautious  minimal
  183. (/home/ishikawa/KERMIT/new-kermit/receive/) C-Kermit>set prefixing
  184.